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TRANSMITTAL OF APPEAL BRIEF (37 C.F.R. 1.192) 

Transmitted herewith in triplicate is the APPEAL BRIEF in this application with 
respect to the Notice of Appeal filed on May 19, 2003. 
This application is on behalf of 

□ Small Entity IEI Large Entity 

Pursuant to 37 C.F.R. 1 .17(f), the fee for filing the Appeal Brief is: 

□ $160.00 (Small Entity) 
IEI $320.00 (Large Entity) 

Enclosed is a check for $320.00 to cover the above fee. 
PETITION FOR EXTENSION . If any extension of time is necessary for the filing of this 
Appeal Brief, and such extension has not otherwise been requested, such an extension 
is hereby requested, and the Commissioner is authorized to charge necessary fees for 
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check in the amount of $320.00 to satisfy the fee under 37 C.F.R. § 1 .17(c). This is an 
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petition for such an extension and request that the fee be charged to Deposit Account 
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I. REAL PARTY IN INTEREST 

The real party in interest is Sun Microsystems, Inc., a corporation of Delaware. 

II. RELATED APPEALS AND INTERFERENCES 

There are no known related pending appeals or interferences directly affected by 
or having a bearing on the decision in the pending appeal. 

III. STATUS OF CLAIMS 

Claims 1, 2, 4-7, and 9-13 have been finally rejected and are the subject of this 
appeal. The claims on appeal are set forth under the heading APPENDIX. In the Final 
Office Action dated December 18, 2002, the Examiner rejected claims 1, 2, 4, 6, 7, 9, 
and 12 under 35 U.S.C. § 102(e) as being unpatentable bv Leach et al. (U.S. Patent 
No. 5,805,885), rejected claims 5 and 10 under 35 U.S.C. § 103(a) as being 
unpatentable over Leach et al. in view of Hailpern et al. (U.S. Patent No. 6,257,937), 
and rejected claims 11 and 13 under 35 U.S.C. § 103(a) as being unpatentable over 
Leach et al. in view of Hailpern et al. and further in view of Hughes (U.S. Patent No. 
6,345,382). 
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IV. STATUS OF AMENDMENTS 

Appellants filed one amendment on October 7, 2002 canceling claims 3 and 8 
and amending claims 1, 6, 12, and 13 as indicated in the attached Appendix. 

V. SUMMARY OF INVENTION 

Many computing systems today utilize programs written in object-oriented 
programming languages. In some object-oriented programming languages, such as the 
Java programming language provided by Sun Microsystems, Inc., classes are defined 
that are a template for creating objects. Classes contain data members that store data 
and methods that act upon the data. Additionally, such programming languages uses 
interfaces that are lists of methods. An interface differs from a class because it 
declares methods and is not capable of implementing them. 

The source code for classes, interfaces, and methods are usually written by a 
user and compiled on a computing system during a stage referred to as "compile-time." 
After the source code is complied, a computing system may execute the source code 
during a stage known as "runtime." Because a class typically has to be built offline and 
then complied, the interfaces implemented by that class must be known while the class 
is being built before runtime. In some instances, however, a user or process may 
require use of an interface that may not be known or may be changing during runtime of 
a program. Conventionally, to implement a single functionality on multiple interfaces of 
varying types, code needs to be created for each interface to carry out the functionality. 

3 
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Further, a class needs to be generated before runtime that implements a list of 
interfaces, and code for each method of an interface being implemented needs to be 
written and complied before runtime. 

The present invention addresses the above problems by providing a system and 
method for dynamically generating a proxy class during runtime that implements a list of 
interfaces specified at runtime. Method invocations on an instance of the proxy class 
are encoded and dispatched to another object that handles method invocations. In one 
aspect related to the present invention, the proxy class generated at runtime does not 
require the implemented interfaces and their methods to be known before runtime. 
Accordingly, interfaces that may be used during execution of a program may change 
during runtime before the creation of the proxy class. Moreover, the proxy class may 
provide uniform implementation of multiple interface types without requiring specialized 
code for each interface. 



VI. 



ISSUES 



The issues in this Appeal are: 

(1 ) whether the Examiner's rejection of claims 1 , 2, 4, 6, 7, 9, and 1 2 under 
35 U.S.C. § 102(e) as being unpatentable by Leach et al. can be affirmed when the 
reference does not teach every recitation of these claims including dispatching a 
request to an object to facilitate processing of a method of an interface specified at 
runtime and returning a result of the processed method by the object, as recited in 
claims 1 , 6, and 12, and the specifying steps recited in claims 4 and 9; 

4 
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(2) whether the Examiner's rejection of claims 5 and 10 under 

35 U.S.C. § 103(a) as being unpatentable over Leach et al. in view of Hailpern et al. 
can be affirmed when neither reference teaches or suggests every recitation of these 
claims including generating at runtime a class that implements an interface by 
generating code fore each of the methods included in the interfaces and an invocation 
handler, as recited in these claims; and 

(3) whether the Examiner's rejection of claims 1 1 and 13 under 

35 U.S.C. § 103(a) as being unpatentable over Leach et al. in view of Hailpern et al. 
and further in view of Hughes can be affirmed when none of the references teaches or 
suggests every recitation of these claims including an invocation handler and proxy 
class, as recited in these claims. 

VII. GROUPING OF CLAIMS 

In the claims on appeal, claims 1, 5, 6, 10, 11, 12, and 13 are the independent 
claims. The claims on appeal do not stand or fall together. These claims should be 
considered in four groups: 

Group I: 1,2, 6, 7, and 12; 

Group II: 4 and 9; 

Group III: 5 and 10; and 

Group IV: 11 and 13. 

The claims have been placed in these groups due to their common subject 
matter. Appellants, however, have addressed the outstanding rejections in accordance 
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with the rejections themselves instead of the above identified groupings. 



VIII. ARGUMENT 



a. 



Summary of Arguments 



The Rejection of Claims 1. 2. 4. 6-9, and 12 
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Appellants appeal the rejection of claims 1 , 2, 4, 6, 7, 9, and 12 under 
35 U.S.C. § 102(e) as being unpatentable by Leach et al. because the reference does 
not teach each and every step and/or element of these claims. The Examiner's 
rejection should be reversed for the following reasons. First, the citations from 
Leach et al. relied upon by the Examiner do not show dispatching the request to an 
object, as recited in claims 1, 6, and 12. Second, the portions of Leach et al. cited by 
the Examiner relate to static aggregation that requires knowledge of interfaces before 
runtime, which teaches away from the recitations of claims 1 , 6, and 12. Third, the 
dynamic aggregation aspects taught by Leach et al. merely require registering 
interfaces as they are instantiated, and do not process methods of the interfaces or 
dispatch a request to an object to facilitate such processing, as recited in claims 1 , 6, 
and 12. Fourth, the Examiner's interpretation of Leach et al. in view of the combination 
of steps and/or elements recited in claims 1, 6, and 12, respectively, is improper. And 
fifth, returning pointers to exposed interfaces, as taught by Leach et aL is not the same 
as returning a result of the processed method, as recited in claims 1, 6, and 12. 

Further, the Examiner's rejection of claims 4 and 9 should be reversed because 
retrieving a reference to an aggregated interface is not the same as specifying an object 
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to process method invocations on a created instance of a class that implements an 
interface specified at runtime. 

The Rejection of Claims 5 and 10 
Appellants appeal the rejection of claims 5 and 10 under 35 U.S.C. § 103(a) as 
being unpatentable over Leach et al. in view of Hailpern et al. because a prima facie 
case of obviousness has not been made by the Examiner. The rejection of claims 5 
and 10 should be reversed because Leach et al. and Hailpern et al. , alone or in 
combination, fail to teach or suggest the invocation handler recited in claims 5 and 10. 
Further, there is no reasonable expectation of success in implementing a virus scanner 
exception handler, as taught by Hailpern et al. , in the method invocation processes 
taught by Leach et al. Moreover, the Examiner has failed to present any evidence to 
support the conclusion that these references, when combined, render claims 5 and 10 
obvious. Further, presenting class definitions that are programmed before runtime, as 
described in table 3 of Leach et al. , does not show generating a class at runtime that 
implements an interface by generating code for each of a plurality of methods of an 
interface indicated at runtime. 

The Rejection of Claims 11 and 13 
Appellants appeal the rejection of claims 11 and 13 under 35 U.S.C. § 103(a) as 
being unpatentable over Leach et al. in view of Hailpern et al. and further in view of 
Hughes because a prima facie case of obviousness has not been made by the 
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Examiner. The rejection of claims 1 1 and 13 should be reversed because none of the 
applied references teaches or suggests dispatching a request to an invocation handler 
object and returning a value from the handler object to a proxy class instance, as 
recited in claim 1 1 . Further, the references do not teach or suggest a processor for 
generating the proxy class at runtime, receiving a request to access a method of an 
interface specified at runtime, and dispatching the request to the object to facilitate 
processing of the requested method of the interface, as recited in claim 13. In addition 
to the deficiencies noted above, the Examiner's assertion that Hughes teaches a proxy 
class that is generated at runtime is incorrect. Rather, the proxy class disclosed by 
Hughes includes code that is generated by a manufacturer before runtime. 

b. Summary of Claims 

Claim 1 is drawn to a method in a data processing system that comprises the 
steps of generating at runtime a class that implements an interface specified at runtime 
having a method and creating an instance of the class. The claimed process also 
involves receiving by the class instance a request to process the method of the 
interface, dispatching the request to an object to facilitate processing of the method of 
the interface, and returning a result of the processed method by the object. 

Claim 6 is drawn to a computer-readable medium containing instructions for 
controlling a data processing system to perform the method described above with 
reference to claim 1 . Claim 12 is drawn to a data processing system comprising 
elements that perform operations similar to the process steps described above with 

8 
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reference to claim 1. Claims 2, 4 and 7, 9 depend from claims 1 and 6, respectively, 
and are drawn to process steps for generating at runtime a class that implements more 
than one interface specified at runtime, and specifying an object to process method 
invocations on the instance, respectively. 

Claim 5 is drawn to a method in a data processing system having an invocation 
handler that comprises the steps of receiving at runtime an indication of at least one 
interface having a plurality of methods and generating at runtime a class that 
implements the interface by generating code for each of the methods that dispatches 
an invocation of the method to the invocation handler. Claim 10 is drawn to a 
computer-readable medium containing instructions for controlling a data processing 
system having an invocation handler to perform the method described above with 
reference to claim 5. 

Claim 1 1 is drawn to a method in a data processing system having a proxy class 
implementing a list interfaces specified at runtime, an instance of the proxy class, and 
an invocation handler object for executing methods contained by the interfaces. The 
claimed method comprises the steps of determining interfaces to be implemented by 
the proxy class and generating at runtime the proxy class implementing the determined 
interfaces. The method further includes receiving a request by the proxy class instance 
to invoke a method of an interface implemented by the proxy class, dispatching the 
request.to the invocation handler object, returning a value from the invocation handler 
object to the proxy class instance, and returning the value from the proxy class 
instance. 
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Claim 13 is drawn to a data processing system that comprises a memory and a 
processor. The memory contains a proxy class, an instance of the proxy class, an 
interface specified at runtime having methods, and an object for handling method 
invocations. The proxy class contained in the memory implements the interface. The 
processor generates the proxy class at runtime, receives a request to access a method 
of the interface and dispatching the request to the object to facilitate processing of the 
requested method of the interface. 



c. The Examiner's position that Leach et al. teaches the recitations of 
claims 1, 2, 6, 7, and 12 must be reversed because the reference fails to 
teach the steps and/or elements of dispatching the request and returning a 
result, as recited in the claims. 



In an attempt to reject claims 1 , 2, 6, 7, and 12 under 35 U.S.C. § 102(e), the 
Examiner asserts that Leach et al. teaches every recitation of these claims. Appellants 
respectfully submit that the Examiner has failed to establish that Leach et al. teaches all 
of the recitations of these claims. 

Leach et al. discloses a method and system for aggregating objects within an 
enclosed object. The method and system allows for static and dynamic aggregation. In 
static aggregation, an interface of an enclosing object knows in advance (e.g., before 
runtime) how to return an identifier to an external interface of an enclosed object. In 
dynamic aggregation, an enclosed object is added to the enclosing object after the 
enclosing object is instantiated. Once included in the enclosing object, a reference to 
an interface of the enclosed object may be returned in response to an external request 

10 
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to access the interface (see Leach et al. . Abstract, col. 1 1 , lines 23-34 and col. 21 , line 
65 to col. 22, line 21). 

In contrast, claim 1 recites a combination of steps including, among other things, 
dispatching a request to an object to facilitate processing of a method of an interface 
specified at runtime, and returning a result of the processed method by the object. 

The Examiner asserts that Leach et al. "discloses dispatching the request to an 
object to facilitate processing of the method of the interface (Fig. 7C, and requests 
received by an enclosed object are passed to the enclosing object, line 67 column 22 to 
line 1 column 23)" (see Final Office Action, page 6, lines 14-20). Appellants respectfully 
disagree with this assertion for several reasons. 

First, the block diagram illustrated in Fig. 7C of Leach et al. (referenced by the 
Examiner) shows a multitype object ("MTO") after the addition of an interface using a 
particular method (e.g., AddObject). A MTO is an object capable of aggregating objects 
of varying types (see Leach et al. . col. 23, lines 14-16). The lUnknown interface 
included in the MTO is capable of providing a pointer to an external interface and/or 
other MTO interfaces (see Leach et al. . col. 24, lines 27-44). Accordingly, the MTO 
taught by Leach et al. does not show dispatching a request to an object to facilitate 
processing of the method of an interface, as recited in claim 1 . 

Second, the ability of Leach et al. to pass requests received by an enclosed 
object to an enclosing object (cited by the Examiner, see Final Office Action, page 5, 
paragraph 6) is associated with static aggregation (see Leach etal. . col. 22, line 49 to 
col. 23, line 3). As explained, static aggregation requires that an enclosing object have 

11 



F I N N EG AN 
HENDERSON 
FARABOW 
CAR RETT & 
DUNNERkH 

1300 I Street, NW 
Washington, DC 20005 
202.408.4000 
Fax 202.408.4400 
www.finnegan.com 



advance (i.e., before runtime) knowledge of the interfaces it wishes to aggregate (see 
Leach et al. , col. 1 1 , lines 15-23). Claim 1 includes the step of generating at runtime a 
class that implements an interface specified at runtime having a method. Accordingly, 
the static aggregation process of passing of requests to an enclosing object discussed 
by Leach et al. cannot teach the dispatching step of claim 1 because this step includes 
dispatching the request to an object to facilitate processing of a method of the interface 
that is specified at runtime. 

Third, the dynamic aggregation processes disclosed by Leach et al. in col. 23, 
lines 4-23, also fail to teach the dispatching step of claim 1 . According to Leach et al. , 
the enclosing object "provides a method for registering instantiated interfaces and for 
later retrieving references to them." (see Leach etal. . col. 23, lines 5-7). Therefore, 
Leach et al. requires an enclosing object method to register interfaces as they are 
instantiated and only provides references to the interfaces. Leach et al. does not teach 
processing the method of the interface, much less dispatching a request to an object to 
facilitate the processing of the method. Instead, Leach et al. teaches an enclosing 
object (e.g., multitype object) that uses a method to retrieve references to registered 
interfaces. Accordingly, Leach et al. cannot teach the dispatching step of claim 1 
because the reference does not disclose dispatching a request to an object to facilitate 
processing of a method of an interface. The method invoked by the enclosing object as 
taught by Leach et al. is not an object. Further, the enclosing object taught by Leach et 
aL cannot be equivalent to the object of claim 1 that receives the dispatched request 
because the enclosing object performs aggregation services which are not associated 

12 
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with the processing of any methods of interfaces implemented by the enclosing object. 
The aggregation services merely add objects and interface lists to an enclosing object 
to allow the enclosing object to retrieve pointers to interfaces implemented by the 
enclosing object. 

Additionally, Appellants submit that the Examiner has incorrectly interpreted of 
Leach et al. in view of the combination of steps recited in claim 1 . For example, the 
Examiner asserts that Leach et al. teaches generating at runtime a class that 
implements an interface specified at runtime having a method and creating an instance 
of the class (see Final Office Action, page 2, lines 19-21). In particular, the Examiner 
asserts that the "objects" disclosed in col. 11, lines 15 and 21-22 of Leach et al. are the 
same as the class instance created in claim 1 . Appellants disagree. The objects 
created by Leach et al. are enclosed objects which are objects or interfaces added to 
an enclosing object. The enclosed objects are those objects or interfaces implemented 
during runtime and are not the same as the class instance as specified in claim 1 . 

The Examiner also asserts that Leach et al. teaches returning a result of a 
processed method, as recited in claim 1 , and contends that Appellants' response filed 
on October 7, 2002 includes remarks that argue a "limitation that is disclosed in the 
specification but not claimed before" (see Final Office Action, page 6, lines 1-3). 
Appellants respectfully disagree with this assertion as well. 

Claim 1 was amended in the response filed October 7, 2002, to include the step 
of returning a result of the processed method by the object. Recitations that are similar 
(albeit not identical) to this added step were recited in claim 3, which was canceled in 
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the October 7, 2002 response. Accordingly, Appellants traverse the Examiner's 
assertions that Appellants are arguing recitations not previously claimed, and requests 
that the Examiner properly address the arguments presented below corresponding to 
the returning step recited in claim 1 . 

Leach et al. does not teach returning a result of the processed method by the 
object, as recited in claim 1. As admitted by the Examiner, the Query Interface method 
implemented by Leach et al. returns pointers to exposed interfaces (see Final Office 
Action, page 3, lines 6-8). Returning pointers is not the same as returning a result of a 
processed method of the interface specified at runtime, as recited in claim 1. In fact, 
Leach et al. does not even disclose processing a method of an interface to return a 
result. Instead, Leach et al. processes a method in an enclosing object (e.g., multitype 
object) that returns references to interfaces added to the enclosing object (see Leach et 
aL, col. 23, lines 5-7). Accordingly, Leach et al. cannot teach the returning step of claim 
1 because the reference does not teach processing a method of an interface enclosed 
in the enclosing object, but instead processes a single method of the enclosing object 
to return a pointer to an enclosed interface. Because Leach et al. fails to teach every 
recitation of claim 1 , Appellants respectfully request that the Board reverse the rejection 
of claim 1. 

Claims 6 and 12 include recitations similar to those of claim 1 . As explained, 
claim 1 is distinguishable from Leach et al. Accordingly, claims 6 and 12 are also 
distinguishable from this reference for the same reasons set forth in connection with 
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claim 1 , and Appellants respectfully request that the Board reverse the rejection of 
claims 6 and 12. 

Claims 2 and 7 depend from claims 1 and 6, respectively. As explained, claims 
1 and 6 are distinguishable from Leach et al. Accordingly, claims 2 and 7 are also 
distinguishable from this reference for the same reasons set forth in connection with 
claims 1 and 6, and Appellants respectfully request that the Board reverse the rejection 
of claims 2 and 7. 



d. The Examiner's position that Leach et al. teaches the recitations of 
claims 4 and 9 must be reversed because determining which interface to 
retrieve and how to invoke the interface is not the same as the specifying 
steps recited in claims 4 and 9, and the query function member taught by 
Leach et al. is not an object and there is no evidence in the reference that 
the function member is specified when a multitype object is created. 



In support of the rejection of claims 4 and 9 under 35 U.S.C. § 102(e), the 
Examiner asserts that Leach et al. teaches the step of specifying an object, which is 
recited in claims 4 and 9, at col. 23, lines 9-10 (see Final Office Action, page 3, lines 
1 3-1 5). Appellants respectfully disagree for the following reasons. 

First, the process of determining which interface to retrieve and how to invoke 
the interface as taught by Leach et al. is not the same as the specifying step recited in 
claims 4 and 9. As explained in the October 7, 2002 response, Leach et al. provides a 
method for modifying a determination of which interfaces to retrieve and how to invoke 
them "in combination if more than one instance of the same interface is present in the 
aggregate object" (i.e., enclosing object) (see Leach et al. . col. 23, lines 9-12). This 
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process taught by Leach et al. is not equivalent to specifying an object to process 
method invocations on the instance, as recited in claims 4 and 9 because, at the very 
least, there is no specification of an object that processes method invocations. 
Moreover, the method provided bv Leach et al. is limited to information on how to 
invoke interfaces in combination if more than one instance of the same interface is 
present. This limitation has no relationship to the recitations of claims 4 and 9. 

The Examiner responds to these arguments in the Advisory Action by simply 
reiterating the position set forth in the Final Office Action, /.e., that the disclosure in col. 
23, lines 9-10 of Leach et al. teaches the specifying step of claim 4. Accordingly, the 
Examiner has yet to present evidence that Leach et al. anticipates claims 4 and 9 in 
light of Appellants' arguments included in the October 7 and February 1 1 responses. 
Because the Examiner has not shown that Leach et al. teaches the recitations of these 
claims, Appellants submit that the rejection of this claim under 35 U.S.C. § 102(e) is 
improper and should be reversed. 

Second, the query function member that is invoked by Leach et al. merely 
retrieves a reference to an aggregated interface, and thus cannot teach the step of 
specifying an object to process method invocations on the instance, as recited in claim 
4. The Examiner appears to take the position that the query function member of the 
multitype object taught by Leach et al. is the same as the object specified in claims 4 
and 9. Appellants disagree on this point as well. The query function member is not an 
object and there is no evidence in Leach et al. that shows the function member is even 
specified when the multitype object is created. Therefore, the invocation of a query 
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function member of the multitype object taught by Leach et al. is not the same as the 
specifying step of claims 4 and 9. 

Because Leach et al. fails to teach every recitation of claims 4 and 9, Appellants 
respectfully request that the Board reverse the rejection of these claims. 



e. The Examiner's position that Leach et al. and Hailpern et al. 
collectively suggest the recitations of claims 5 and 10 must be reversed 
because these references fail to teach or suggest a handler that is in the 
same context as the invocation handler of these claims, there is no 
reasonable expectation of success in the combination of these references, 
and the class definitions described in table 3 of Leach et al. do not show 
generating at runtime a class that implements an interface, as recited in the 
claims. 



Appellants traverse the rejection of claims 5 and 10 under 35 U.S.C. § 103(a) 
because a prima facie case of obviousness has not been made by the Examiner. To 
establish a prima facie case of obviousness under 35 U.S.C. § 103(a), each of three 
requirements must be met. First, the reference or references, taken alone or combined, 
must teach or suggest each and every element recited in the claims (see 
M.P.E.P. § 2143.03 (8 th ed. 2001)). Second, there must be some suggestion or 
motivation, either in the references themselves or in the knowledge generally available 
to one of ordinary skill in the art to combine the references in a manner resulting in the 
claimed invention. Third, a reasonable expectation of success must exist. Moreover, 
each of these requirements must "be found in the prior art, and not be based on 
applicants disclosure" (see M.P.E.P. § 2143 (8 th ed. 2001)). 
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In rejecting claims 5 and 10, the Examiner admits that Leach et al. does not 
teach an invocation handler (see Final Office Action, page 4, paragraph 4). In an effort 
to supplement this missing element, the Examiner asserts that the process execution 
handler taught by Hailpern et al. is equivalent to an invocation handler and that it would 
have been obvious to apply the execution handler to the system of Leach et al. 
"because this allows dynamic aggregating objects" (see Final Office Action, page 4, 
lines 16-20). 

In the responses filed October 7, 2002 and February 1 1, 2003, Appellants 
presented arguments distinguishing claims 5 and 10 from Leach et al. and Hailpern et 
aL and explained why the Examiner failed to establish a prima facie case of 
obviousness. In response, the Examiner addressed one of the arguments presented by 
Appellants by merely stating that "while this may be true [the handler of Haibern et al. is 
not in the same context as the handler claimed] it does not preclude using Hailpern in 
the claim rejections." The Examiner states nothing else regarding the issues involved 
with the rejections of claims 5 and 10 under 35 U.S.C. § 103(a). 

Not only does the Examiner's position demonstrate an admission that the 
handler taught by Hailpern et al. is non-analogous to Appellants claimed handler and 
Leach et al. 's object aggregation environment, but the Examiner is also wrong because 
the fact that Hailpern et al. does not teach or suggest (as Admitted by the Examiner) a 
handler that is in the same context as the invocation handler of claims 5 and 10 does 
preclude using the reference to reject these claims under 35 U.S.C. § 103(a). 
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As explained above, the Examiner has a burden to show (1) that Hailpern et al. 
and Leach et al- taken alone or combined, teaches or suggests each and every 
element recited claims 5 and 10 (see M.P.E.P. § 2143.03 (8 th ed. 2001)), (2) that there 
is some suggestion or motivation, either in the references themselves or in the 
knowledge generally available to one of ordinary skill in the art to combine the Hailpern 
et al. and Leach et al. in a manner resulting in the inventions recited in claims 5 and 10, 
and (3) that there is a reasonable expectation of success in making the combination. 

The Examiner has failed to meet this burden and in fact has failed to make any 
of these required showings in connection with the rejection of claims 5 and 10. As 
explained by Appellants in previous responses, the process execution handler taught by 
Hailpern et al. carries out "necessary processing" for a server that performs virus 
checking in a server network environment (see Hailpern et al. , col. 15, lines 48-40). 
The execution handler is not an invocation handler that receives method invocations, as 
recited in claims 5 and 10. 

Also, there is no reasonable expectation of success in implementing a virus 
scanner exception handler, as taught bv Hailpern et al- in the method invocation 
processes taught by Leach et al. One of ordinary skill in the art would have 
appreciated, at the time of the invention, that such a combination is not suggested in 
the references themselves in any possible interpretation and that the asserted 
combination is not feasible because the virus scanner taught by Hailpern et al. does not 
perform in a manner consistent with the handler recited in claims 5 and 10. If anything, 
the combination asserted by the Examiner merely results in Leach et al. using virus 
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scanning processes, which is not analogous to Appellants' claimed invention. Further, 
there is no suggestion in either reference that would motivate one of ordinary skill in the 
art to use virus exception handlers in the system for aggregating objects taught by 
Leach et al. 

Moreover, when given the opportunity to elaborate on the rejection of claims 5 
and 10, the Examiner merely concludes that Hailpern et al. may be used to reject these 
claims without presenting evidence to support the conclusion (see final Office Action, 
page 6, lines 11-13). Appellants submit the Examiner's position is improper and 
requests that the Board reverse rejection of claims 5 and 10. 

The Examiner also maintains the position that Leach et al. teaches generating at 
runtime a class that implements the interface by generating code for each of the 
methods included in the interface, as recited in claims 5 and 10 (see Final Office Action, 
page 6, lines 14-21 ). The Examiner asserts that Leach et al. discloses this recitation in 
Code table 3 and columns 11-14. 

The Examiner is wrong. The code table 3 taught by Leach et al. is a listing of 
pseudo code for class and method definitions of an object enclosed in an aggregate 
object (see Leach et al. , col. 14, lines 23-28). There is no mention or suggestion in 
Leach et al. . particularly associated with code table 3, of generating a class at runtime 
that implements an interface by generating code for each of the methods in the 
interface, as recited in claims 5 and 10. Further, merely presenting a class definition 
does not show generating at runtime a class that implements an interface by 
generating code for each of a plurality of methods of an interface indicated at runtime. 
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Also, the objects created dynamically at run time, as disclosed in column 1 1 , lines 22- 
23 of Leach et al. (cited by the Examiner) are instances of statically aggregated 
objects, and not a class that implements an interface, as recited in claims 5 and 10. 
Accordingly, Leach et al. cannot teach or suggest the generating step recited in these 
claims. 

Because Leach et al. fails to teach or suggest the recitations of claims 5 and 10, 
and Hailpern et al. fails to make up for the deficiencies of Leach et al. . Appellants 
request that the Board reverse the rejection of these claims. 



f. The Examiner's position that Leach et al. . Hailpern et al. . and Hughes 
collectively suggest the recitations of claims 11 and 13 must be reversed 
because these references fail to teach or suggest a handler object and a 
proxy class as recited in these claims, returning a value from the object to 
a proxy class instance, as recited in claim 11, and a processor for 
generating a proxy class at runtime, receiving a request, and dispatching a 
request, as recited in claim 13. 



In rejecting claims 11 and 13 under 35 U.S.C. § 103(a), the Examiner relies on 
the rejections of claims 1 , 2 and 5 (referring to the teachings of Leach et al. and 
Hailpern et al. ). Further, the Examiner relies on Hughes to teach a proxy class, as 
recited in these claims. Appellants disagree with the Examiner's position for the 
following reasons. 

Leach et al. and Hailpern et al. . alone or in combination, do not teach or suggest 
a handler that is in the same context as the handler object of claims 1 1 and 13. As 
explained above with reference to the rejection of claims 5 and 10, the process 
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execution handler taught by Hailpern et al. carries out "necessary processing" for a 
server that performs virus checking in a server network environment (see Hailpern et 
aL, col. 15, lines 48-40). The execution handler is not a handler object, as recited in 
claims 1 1 and 13. Further, as explained, the code table 3 disclosed by Leach et al. 
does not teach generating at runtime a class implementing a determined interface. 
Claim 1 1 is also distinguishable from Hughes because that reference does not teach or 
suggest, alone or in combination with Leach et al. and Hailpern et al. . at least 
dispatching a request to an invocation handler object and returning a value from the 
handler object to a proxy class instance, as recited in the claim. 

Further, the Examiner maintains the position that Hughes teaches a proxy class 
generated at runtime, as recited in claims 1 1 and 13. The Examiner reaches this 
conclusion in the Final Office Action reiterating the arguments presented in the Office 
Action dated July 17, 2002 without providing evidence or an explanation to support the 
conclusion in light of Appellants arguments presented in the October 7, 2002 and 
February 11, 2003 response (see Final Office Action, page 6, lines 1-10 and page 7, 
lines 1-4, and the Advisory Action, page 2) . Accordingly, Appellants reiterate the 
arguments presented in the October 7, 2002 response and respectfully request that the 
Examiner and the Board address them accordingly. 

As explained by Appellants, the proxy class disclosed by Hughes is not 
generated at runtime. Instead, a manufacturer generates code for interfaces, and other 
functionalities associated with the proxy class (see Hughes , col. 4, lines 18-31 and 60- 
67). As disclosed by Hughes , a proxy class is not generated at runtime, but rather a 
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user dynamically specifies at runtime the "customization" of an instance of the proxy 
class (see Hughes , col. 8, lines 6-8). Therefore, Hughes cannot teach a proxy class, as 
recited in claims 11 and 13. 

Because Hughes , Leach et al. and Haibern et aL alone or in combination, fail to 
teach or suggest the recitations of claims 1 1 and 13, Appellants respectfully request 
that the Board reverse the rejection of these claims. 

IX. CONCLUSION 

The final rejection of claims 1 , 2, 4, 6, 7, 9, and 12 should be reversed because 
Leach et al. does not teach each and every recitation of these claims. Further, the final 
rejection of claims 5, 1 0, 1 1 , and 1 3 should be reversed because the Examiner has not 
established a prima facie case of obviousness in rejecting these claims under 35 U.S.C. 
§ 103(a). Accordingly, Appellants respectfully request such reversals. 
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To the extent any extension of time under 37 C.F.R. § 1.136 is required to obtain 
entry of this Appeal Brief, such extension is hereby respectfully requested. If there are 
any fees due under 37 C.F.R. §§ 1.16 or 1.17 which are not enclosed herewith, 
including any fees required for an extension of time under 37 C.F.R. § 1.136, please 
charge such fees to our Deposit Account No. 06-0916. 



Dated: July 14, 2003 

Post Office Address (to 
which correspondence is 
to be sent) 



Respectfully submitted, 

FINNEGAN, HENDERSON, FARABOW, 
GARRETT & DUNNER, LLP. 




Joseph E. Palys 
Reg. No. 46,508 



Finnegan, Henderson, Farabow, 

Garrett & Dunner, L.L.P. 
1300 I Street, N.W. 
Washington, D.C. 20005 
(202) 408-4000 
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APPENDIX 

1 . A method in a data processing system comprising the steps of: 
generating at runtime a class that implements an interface specified at runtime 

having a method; 

creating an instance of the class; 

receiving by the class instance a request to process the method of the interface; 
dispatching the request to an object to facilitate processing of the method of the 
interface; and 

returning a result of the processed method by the object. 

2. The method of claim 1 , wherein the step of generating a class further includes 
the step of: 

generating at runtime a class that implements more than one interface specified 
at runtime, each interface having one or more methods. 

4. The method of claim 1 , wherein the step of creating an instance further 
includes the step of: 

specifying an object to process method invocations on the instance. 
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5. A method in a data processing system having an invocation handler, 
comprising the steps of: 

receiving at runtime an indication of at least one interface having a plurality of 
methods; and 

generating at runtime a class that implements the interface by generating code 
for each of the methods that dispatches an invocation of the method to the invocation 
handler. 

6. A computer-readable medium containing instructions for controlling a data 
processing system to perform a method comprising the steps of: 

generating at runtime a class that implements an interface specified at runtime 
having a method; 

creating an instance of the class; 

receiving by the class instance a request to process the method of the interface; 
dispatching the request to an object to facilitate processing of the method of the 
interface; and 

returning a result of the processed method by the object. 

7. The computer-readable medium of claim 6, wherein the step of generating a 
class further includes the step of: 
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generating at runtime a class that implements more than one interface specified 
at runtime, each interface having one or more methods. 

9. The computer-readable medium of claim 6, wherein the step of creating an 
instance further includes the step of: 

specifying an object to process method invocations on the instance. 

10. A computer-readable medium containing instructions for controlling a data 
processing system having an invocation handler to perform a method comprising the 
steps of: 

receiving at runtime an indication of at least one interface having a plurality of 
methods; and 

generating at runtime a class that implements the interface by generating code 
for each of the methods that dispatches an invocation of the method to the invocation 
handler. 

1 1 . A method in a data-processing system having a proxy class implementing a 
list of interfaces specified at runtime, the interfaces containing methods, the system 
further having an instance of the proxy class and an invocation handler object for 
executing the methods contained by the interfaces, the method comprising the steps of: 



generating at runtime the proxy class implementing the determined interfaces; 
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receiving a request by the proxy class instance to invoke a method of an 
interface implemented by the proxy class; 

dispatching the request to the invocation handler object; 

returning a value from the invocation handler object to the proxy class instance; 

and 

returning the value from the proxy class instance. 

12. A data-processing system comprising: 

means for generating at runtime a class that implements an interface specified at 
runtime having a method; 

means for creating an instance of the class; 

means for receiving by the class instance a request to process the method of the 
interface; 

means for dispatching the request to an object to facilitate processing of the 
method of the interface; and 

means for returning a result of the processed method by the object. 

1 3. A data-processing system comprising: 

a memory containing a proxy class, an instance of the proxy class, an interface 
specified at runtime having methods, and an object for handling method invocations, 
the proxy class implementing the interface; and 
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a processor for generating the proxy class at runtime, receiving a request to 
access a method of the interface and dispatching the request to the object to facilitate 
processing of the requested method of the interface. 
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